---In DynoMotion@{{emailDomain}}, <tk@...> wrote:

Hi Eric,

I think the issue might be related to your definition of the term "work offset"

There are two types of independent offsets in GCode:

#1 global/coordinate offsets G92/G52

#2 Fixture Offsets G54/G55/G56...

I think a difference between Mach3 and KMotionCNC is that most "Zero" buttons in Mach3 adjust the Fixture Offsets where in KMotionCNC the Zero buttons near the DROs adjust the global offsets.  The "working coordinates" are always a function of both. 

There were a number of earlier posts on this.  You can add buttons to adjust the Fixture Offsets instead of the Global offsets if that works better for you

It may help to view the edit fixture offsets screen to understand better what happens.

BTW the global offsets are saved in vars #5211...#5216 a solution for your subroutine may be to save them and then restore them. After changing the Vars a G92.3 will make the offsets active.

Regards

TK

Group: DynoMotion	Message: 8833	From: eric_kato_sanders	Date: 12/29/2013
Subject: Re: G52 implementation anomoly

I read your earlier post.  I didn't go through the earlier threads so let me apologize in advance if I'm miss understanding what you are driving at. It does appear that G92 is global and *should* affect all fixture offsets.  Tormach, which uses Mach3, also specifically states: "The axis offsets are always used when motion is specified in absolute distance mode using any of the fixture coordinate systems. Thus, all fixture coordinate systems are affected by G92." (http://www.tormach.com/g92_offsets.html) I

Group: DynoMotion	Message: 8834	From: eric_kato_sanders	Date: 12/29/2013
Subject: Re: G52 implementation anomoly

I think the big difference is that Mach uses G52 as a temporary offset.  The G52 value simply shifts the origin by that amount. A G52 X5 shifts all X positions by 5.  G52 X0 clears that register so they moves are no longer shifted. current position = machine position+g92 offset+g52 temporary offset + fixture offset From the tormach site: "G52 - Temporary Coordinate System Offset " "When G52 is executed, the origin of the currently active coordinate system moves by the values given. The effect of G52 is cancelled by programming: G52 X0 Y0 etc." In your implementation, if you have G52 X5, it shifts global offset away such that from the current X position, we are 5 away from the machine coordinates origin. Personally, I much prefer the use of G52 as a straight temporary offset. In my g code, I got around this by programming a fixture offset G10L2P1 x#101 and G10L2P1 x0 y0 z0 to clear it this of course isn't very portable since if a person is actually using the fixture offsets, you will screw that up. ---In DynoMotion@{{emailDomain}}, <tk@...> wrote: Hi Eric, I think the issue might be related to your definition of the term "work offset" There are two types of independent offsets in GCode: #1 global/coordinate offsets G92/G52 #2 Fixture Offsets G54/G55/G56... I think a difference between Mach3 and KMotionCNC is that most "Zero" buttons in Mach3 adjust the Fixture Offsets where in KMotionCNC the Zero buttons near the DROs adjust the global offsets.  The "working coordinates" are always a function of both.  There were a number of earlier posts on this.  You can add buttons to adjust the Fixture Offsets instead of the Global offsets if that works better for you It may help to view the edit fixture offsets screen to understand better what happens. BTW the global offsets are saved in vars #5211...#5216 a solution for your subroutine may be to save them and then restore them. After changing the Vars a G92.3 will make the offsets active. Regards TK Group: DynoMotion Message: 8835 From: Tom Kerekes Date: 12/29/2013 Subject: Re: G52 implementation anomoly Hi Eric, G52 and G92 alter the same global offset.  They are just two different ways of changing the same offset.  G52 sets it directly.  G92 adjusts it to make the current working position the value specified.  I think you will find this true for most systems: Mach3/Tormach/LinxCNC... I think the issue you had was because the code assumed there was no global offset to begin with when there was.  So setting it and clearing it lost the original offset.  Another solution would be to adjust the global offset and then adjust it back.  That method would also be compatible with Mach3. Thanks for pointing out the issue.  We should offer an option for the Zero/Set buttons to alter the fixture offsets rather than the global offsets.  That is the way EC would like it handled also. Regards TK Group: DynoMotion Message: 8836 From: eric_kato_sanders Date: 12/29/2013 Subject: Re: G52 implementation anomoly Hi Tom, Thanks for the responses.  I'm not sure why G52 X0 it works fine under Mach. Within Mach, when you zero on your work piece, and then issue a G52 X0 command, it does not alter your work piece zero, it just removes the offset you imposed by the previous G52.  I think that under Mach3 that G92 are G52 have separate offsets.  One does not effect the other. Would it be very difficult to separate the two?  I suppose you would run into compatibility issues with past programs that wouldn't expect the new behavior, but it would be great to make it an option.  Would it only be a change to the GCodeInterpreter dll or to the KMotion firmware as well? Eric Group: DynoMotion Message: 8837 From: eric_kato_sanders Date: 12/31/2013 Subject: Re: G52 implementation anomoly Hi Tom, I took a look at the GCodeInterpreter source.  It doesn't look like an easy task to allow different G52 functionality as an option. I tried your suggestion on saving the 5211, 5212,... variables and then offsetting them, then setting it back. This works fine.  The only danger is if you end don't end up letting the GCode run to completion for some reason, you lose your work piece zero.  From that standpoint, I think perhaps writing to the fixture offsets is safer, perhaps using the last one in the list.  Is G53.9 the last fixture offset? Eric Group: DynoMotion Message: 8842 From: Tom Kerekes Date: 1/1/2014 Subject: Re: G52 implementation anomoly Hi Eric, We've added an option to to have KMotionCNC's Zero/Set Buttons to alter Fixture Offsets rather than (G92/G52) Global Offsets. Here is a test Version V4.31r http://dynomotion.com/Software/KMotion431r.exe See the Help Screen Entry here: http://www.dynomotion.com/Help/KMotionCNC/ToolSetupScreenTP.htm#Zero_Using_Fixture_Offsets This Version also has G96 CSS (Constant Surface Speed) added to KMotionCNC.  See description here on how to configure: http://dynomotion.com/Help/KMotionCNC/SpindleControl.htm Please let us know how this works for you. Regarding Fixture Offsets there are 9 selected by: G54 G55 G56 G57 G58 G59 G59.1 G59.2 G59.3 Regards TK Group: DynoMotion Message: 8843 From: ericncn Date: 1/2/2014 Subject: Re: G52 implementation anomoly Thank you Tom! This is really useful to me and I'm sure it'll be useful to most other people, too! Thank you again EC Group: DynoMotion Message: 8844 From: eric_kato_sanders Date: 1/2/2014 Subject: Re: G52 implementation anomoly Thanks Tom, Incidentally, FWIW to the group, this will also solve the potential problem of losing your work piece zero if you have to stop the program before it has a chance to reset the global offsets to their starting values.  Since your work piece zero is now being handled by the fixture offset, you can now simply offset the global offset using G52 like I was before, and be sure to have G54  G52 X0Y0Z0 at the start of the code.  Eric